Methods and system for providing drug pricing information from multiple pharmacy benefit managers (pbms)

ABSTRACT

A system according to certain aspects of the disclosure provides drug pricing information from multiple PBMs to users. For example, the system may obtain, calculate, and/or estimate drug prices that are available under contracts or agreements between PBMs and various pharmacies. These prices may be prices of drugs for purchase at the various pharmacies. In response to requests for prices of particular drugs, the system can display relevant prices. For example, the system displays a price for each pharmacy chain and/or displays prices for a particular geographical area. The users can compare the prices for a particular drug and determine which pharmacy they would like to purchase the drug from. The system can provide a discount coupon that allows the users to purchase the drug at the price listed by the system at the selected pharmacy.

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.61/769,617, filed Feb. 26, 2013, the entire content of which isincorporated herein by reference. Any and all applications for which aforeign or domestic priority claim is identified in the Application DataSheet as filed with the present application are hereby incorporated byreference under 37 CFR 1.57.

BACKGROUND OF THE INVENTION Field of the Invention

This invention relates to managing medical benefits and, moreparticularly, to managing pharmacy benefits to reduce costs.

SUMMARY

According to one aspect, a method of displaying prices for drugs from aplurality of pharmacy benefit managers is provided. The method caninclude providing a user interface using a computer processor. Themethod may further include receiving from the user interface informationidentifying a first drug. The method can additionally include obtaininga first set of prices for the first drug that is associated with a firstpharmacy benefit manager (PBM), wherein a pharmacy benefit managerprocesses a claim relating to a drug and has an agreement with apharmacy relating to a price of one or more drugs, the first set ofprices comprising at least one price for the first drug and each pricein the first set of prices being determined by an agreement between thefirst PBM and a pharmacy. The method can further include obtaining asecond set of prices for the first drug that is associated with a secondpharmacy benefit manager, the second set of prices comprising at leastone price for the first drug and each price in the second set of pricesbeing determined by an agreement between the second PBM and a pharmacy.The method can also include displaying in the user interface at least aportion of the first set of prices and the second set of prices.

In some embodiments, the method may further include receiving aselection of a price from the at least a portion of the first set ofprices and the second set of prices displayed in the user interface. Themethod may also include generating a discount card or a discount couponthat provides access to the selected price for a purchase of the firstdrug at a pharmacy associated with the selected price. In certainembodiments, the selected price may not be available to a customer forthe purchase of the first drug at the pharmacy from a PBM associatedwith the selected price without the discount card or the discountcoupon. In some embodiments, the selected price may be provided under anagreement with the PBM associated with the selected price, and theagreement may be different from an agreement between the PBM associatedwith the selected price and the pharmacy associated with the selectedprice. In some embodiments, the discount card or the discount coupon mayinclude an identification number that is recognized by a PBM associatedwith the selected price.

In certain embodiments, the first PBM can administer claims relating toa first health insurance plan, and an agreement between the first PBMand a first pharmacy may specify a price of the first drug for a memberof the first health insurance plan and a first price of the first drugfor a customer that is not a member of the first health insurance plan.The first set of prices may include the first price of the first drugfor a customer that is not a member of the first health insurance plan.The second PBM can administer claims relating to a second healthinsurance plan, and an agreement between the second PBM and a secondpharmacy may specify a price of the first drug for a member of thesecond health insurance plan and a second price of the first drug for acustomer that is not a member of the second health insurance plan. Thesecond set of prices may include the second price of the first drug fora customer that is not a member of the second health insurance plan. Insome embodiments, the method can further include displaying in the userinterface the first price of the first drug for a customer that is not amember of the first health insurance plan. The method can also include,in response to selection of the first price received from the userinterface, generating a discount coupon for a purchase of the first drugat the first price at the first pharmacy.

In some embodiments, the information identifying the first drug mayinclude a name of the first drug. In certain embodiments, the method mayfurther include receiving from the user interface location information.The method may also include, prior to the displaying at least a portionof the first set of prices and the second set of prices, filtering thefirst set of prices and the second set of prices based on the locationinformation.

In certain embodiments, the at least one price in the first set ofprices may be obtained by using an API provided by the first PBM. Insome embodiments, the at least one price in the first set of prices canbe obtained based on pricing rules for the first drug provided by thefirst PBM.

In some embodiments, the first set of prices may include a first pricefor the first drug determined by an agreement between the first PBM anda first pharmacy and the second set of prices may include a second pricefor the first drug determined by an agreement between the second PBM andthe first pharmacy. The displaying at least a portion of the first setof prices and the second set of prices of the method can includecomparing the first price for the first drug and the second price forthe first drug, and displaying lower of the first price for the firstdrug and the second price for the first drug.

According to another aspect, a system is provided for displaying pricesfor drugs from a plurality of pharmacy benefit managers. The system mayinclude computer hardware comprising one or more computer processors.The system may also include a module executing on the one or morecomputer processors. The module can be configured to receive a requestfor one or more prices for a first drug. The module may be furtherconfigured to obtain a first set of prices for the first drug that isassociated with a first pharmacy benefit manager (PBM), wherein apharmacy benefit manager processes a claim relating to a drug and has anagreement with a pharmacy relating to a price of one or more drugs, thefirst set of prices comprising at least one price for the first drug andeach price in the first set of prices being determined by an agreementbetween the first PBM and a pharmacy. The module may be furtherconfigured to obtain a second set of prices for the first drug that isassociated with a second pharmacy benefit manager, the second set ofprices comprising at least one price for the first drug and each pricein the second set of prices being determined by an agreement between thesecond PBM and a pharmacy. The module can be further configured todisplay in the user interface at least a portion of the first set ofprices and the second set of prices.

In some embodiments, the module may be further configured to receive aselection of a price from the at least a portion of the first set ofprices and the second set of prices displayed in the user interface, andgenerate a discount card or a discount coupon that provides access tothe selected price for a purchase of the first drug at a pharmacyassociated with the selected price. In certain embodiments, the selectedprice may not be available to a customer for the purchase of the firstdrug at the pharmacy from a PBM associated with the selected pricewithout the discount card or the discount coupon. In some embodiments,the selected price may be provided under an agreement with the PBMassociated with the selected price, and the agreement may be differentfrom an agreement between the PBM associated with the selected price andthe pharmacy associated with the selected price. In certain embodiments,the discount card or the discount coupon may include an identificationnumber that is recognized by a PBM associated with the selected price.

In certain embodiments, the first PBM can administer claims relating toa first health insurance plan, and an agreement between the first PBMand a first pharmacy may specify a price of the first drug for a memberof the first health insurance plan and a first price of the first drugfor a customer that is not a member of the first health insurance plan.The first set of prices may include the first price of the first drugfor a customer that is not a member of the first health insurance plan.The second PBM can administer claims relating to a second healthinsurance plan, and an agreement between the second PBM and a secondpharmacy may specify a price of the first drug for a member of thesecond health insurance plan and a second price of the first drug for acustomer that is not a member of the second health insurance plan. Thesecond set of prices may include the second price of the first drug fora customer that is not a member of the second health insurance plan. Insome embodiments, the module may be further configured to display in theuser interface the first price of the first drug for a customer that isnot a member of the first health insurance plan, and in response toselection of the first price received from the user interface, generatea discount coupon for a purchase of the first drug at the first price atthe first pharmacy.

In some embodiments, the first set of prices may include a first pricefor the first drug determined by an agreement between the first PBM anda first pharmacy, and the second set of prices may include a secondprice for the first drug determined by an agreement between the secondPBM and the first pharmacy. The module may perform the displaying atleast a portion of the first set of prices and the second set of pricesat least in part by comparing the first price for the first drug and thesecond price for the first drug, and displaying lower of the first pricefor the first drug and the second price for the first drug.

According to certain aspects, a method of displaying prices for drugsfrom a plurality of pharmacy benefit managers is provided. The methodmay include providing a user interface using a computer processor. Themethod can further include receiving information identifying a firstdrug from the user interface. The method may additionally includeobtaining a first set of prices for the first drug that is associatedwith a first pharmacy benefit manager (PBM), wherein a pharmacy benefitmanager processes a claim relating to a drug and has an agreement withone or more pharmacies relating to a price of one or more drugs, thefirst set of prices comprising at least one price for the first drug andeach price in the first set of prices being determined by an agreementbetween the first PBM and a pharmacy. The method can further includeobtaining a second set of prices for the first drug that is associatedwith a second pharmacy benefit manager, the second set of pricescomprising at least one price for the first drug and each price in thesecond set of prices being determined by an agreement between the secondPBM and a pharmacy. The method may also include ranking the at least oneprice for the first drug in the first set of prices for the first drugand the at least one price for the first drug in the second set ofprices for the first drug in an order that is different from lowest tohighest. The method can also include displaying a price from the rankingin the user interface.

In some embodiments, the ranking of the method may further include, inresponse to determining that the at least one price for the first drugin the first set of prices is higher than or equal to the at least oneprice for the first drug in the second set of prices, ranking the atleast one price in the first set of prices higher than the at least oneprice in the second set of prices. In certain embodiments, the rankingthe at least one price in the first set of prices higher than the atleast one price in the second set of prices may be performed in responseto determining that a difference between the at least one price for thefirst drug in the first set of prices and the at least one price for thefirst drug in the second set of prices does not exceed a thresholdvalue. In some embodiments, wherein the ranking the at least one pricein the first set of prices higher than the at least one price in thesecond set of prices may be based on a first acceptance rate associatedwith the at least one price in the first set of prices and a secondacceptance rate associated with the at least one price in the second setof prices. In certain embodiments, a higher ranked price from theranking is displayed in the user interface. In some embodiments, themethod may further include determining a preferred order for rankingprices from the first PBM and prices from the second PBM. The preferredorder may indicate that prices from the first PBM are to be rankedhigher than prices from the second PBM.

In certain embodiments, a first percentage may indicate a portion ofprices from the first PBM to be displayed in the user interface. Asecond percentage may indicate a portion of prices from the second PBMto be displayed in the user interface. The ranking may include rankingthe at least one price for the first drug in the first set of prices andthe at least one price for the first drug in the second set of pricesbased at least in part on the first percentage and the secondpercentage. In some embodiments, the second percentage may be linked toa threshold value for ranking prices from the first PBM over the secondPBM such that adjusting the second percentage adjusts the thresholdvalue and adjusting the threshold value adjusts the second percentage.

In some embodiments, the first PBM can administer claims relating to afirst health insurance plan, and an agreement between the first PBM anda first pharmacy may specify a price of the first drug for a member ofthe first health insurance plan and a first price of the first drug fora customer that is not a member of the first health insurance plan. Thefirst set of prices may include the first price of the first drug for acustomer that is not a member of the first health insurance plan. Thesecond PBM can administer claims relating to a second health insuranceplan, and an agreement between the second PBM and a second pharmacy mayspecify a price of the first drug for a member of the second healthinsurance plan and a second price of the first drug for a customer thatis not a member of the second health insurance plan. The second set ofprices may include the second price of the first drug for a customerthat is not a member of the second health insurance plan. In certainembodiments, the method can further include displaying in the userinterface the first price of the first drug for a customer that is not amember of the first health insurance plan. The method can also include,in response to selection of the first price received from the userinterface, generating a discount coupon for a purchase of the first drugat the first price at the first pharmacy.

According to other aspects, a system of displaying prices for drugs froma plurality of pharmacy benefit managers is provided. The system caninclude computer hardware comprising one or more computer processors.The system may further include a module executing on the one or morecomputer processors. The module can be configured to provide a userinterface using a computer processor. The module may be furtherconfigured to receive information identifying a first drug from the userinterface. The module may also be configured to obtain a first set ofprices for the first drug that is associated with a first pharmacybenefit manager (PBM), wherein a pharmacy benefit manager processes aclaim relating to a drug and has an agreement with one or morepharmacies relating to a price of one or more drugs, the first set ofprices comprising at least one price for the first drug and each pricein the first set of prices being determined by an agreement between thefirst PBM and a pharmacy. The module may additionally be configured toobtain a second set of prices for the first drug that is associated witha second pharmacy benefit manager, the second set of prices comprisingat least one price for the first drug and each price in the second setof prices being determined by an agreement between the second PBM and apharmacy. The module can be further configured to rank the at least oneprice for the first drug in the first set of prices for the first drugand the at least one price for the first drug in the second set ofprices for the first drug in an order that is different from lowest tohighest. The module may also be configured to display a price from theranking in the user interface.

In some embodiments, the module may perform the ranking at least in partby, in response to determining that the at least one price for the firstdrug in the first set of prices is higher than or equal to the at leastone price for the first drug in the second set of prices, ranking the atleast one price in the first set of prices higher than the at least oneprice in the second set of prices. In certain embodiments, the modulemay perform the ranking the at least one price in the first set ofprices for the first drug higher than the at least one price in thesecond set of prices for the first drug at least in part in response todetermining that a difference between the at least one price for thefirst drug in the first set of prices and the at least one price for thefirst drug in the second set of prices does not exceed a thresholdvalue. In some embodiments, the module may perform the ranking the atleast one price in the first set of prices higher than the at least oneprice in the second set of prices based at least in part on a firstacceptance rate associated with the at least one price in the first setof prices and a second acceptance rate associated with the at least oneprice in the second set of prices. In certain embodiments, a higherranked price from the ranking may be displayed in the user interface. Insome embodiments, the module may be further configured to determine apreferred order for ranking prices from the first PBM and prices fromthe second PBM. The preferred order may indicate that prices from thefirst PBM are to be ranked higher than prices from the second PBM.

In certain embodiments, a first percentage may indicate a portion ofprices from the first PBM to be displayed in the user interface. Asecond percentage may indicate a portion of prices from the second PBMto be displayed in the user interface. The module may perform theranking at least in part by ranking the at least one price for the firstdrug in the first set of prices and the at least one price for the firstdrug in the second set of prices based at least in part on the firstpercentage and the second percentage. In some embodiments, the secondpercentage may be linked to a threshold value for ranking prices fromthe first PBM over the second PBM such that adjusting the secondpercentage adjusts the threshold value and adjusting the threshold valueadjusts the second percentage.

In some embodiments, the first PBM can administer claims relating to afirst health insurance plan, and an agreement between the first PBM anda first pharmacy may specify a price of the first drug for a member ofthe first health insurance plan and a first price of the first drug fora customer that is not a member of the first health insurance plan. Thefirst set of prices may include the first price of the first drug for acustomer that is not a member of the first health insurance plan. Thesecond PBM can administer claims relating to a second health insuranceplan, and an agreement between the second PBM and a second pharmacy mayspecify a price of the first drug for a member of the second healthinsurance plan and a second price of the first drug for a customer thatis not a member of the second health insurance plan. The second set ofprices may include the second price of the first drug for a customerthat is not a member of the second health insurance plan. In someembodiments, the module may be further configured to display in the userinterface the first price of the first drug for a customer that is not amember of the first health insurance plan, and in response to selectionof the first price received from the user interface, generate a discountcoupon for a purchase of the first drug at the first price at the firstpharmacy.

For purposes of summarizing the disclosure, certain aspects, advantagesand novel features of the inventions have been described herein. It isto be understood that not necessarily all such advantages may beachieved in accordance with any particular embodiment of the invention.Thus, the invention may be embodied or carried out in a manner thatachieves or optimizes one advantage or group of advantages as taughtherein without necessarily achieving other advantages as may be taughtor suggested herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an overview of an example system for providing drugprices from multiple Pharmacy Benefit Managers (PBMs), according to oneaspect of the disclosure.

FIG. 2 illustrates an example data flow diagram for providing drugprices from multiple Pharmacy Benefit Managers, according to one aspectof the disclosure.

FIG. 3 illustrates one embodiment of an example process for displayingdrug prices from multiple for Pharmacy Benefit Managers.

FIG. 4 illustrates another embodiment of an example process fordisplaying drug prices from multiple for Pharmacy Benefit Managers.

FIG. 5 illustrates one embodiment of an example process for ranking drugprices from multiple for Pharmacy Benefit Managers.

FIG. 6 illustrates one embodiment of a discount coupon.

FIG. 7 illustrates one embodiment of a user interface for providing drugprices from various Pharmacy Benefit Managers.

FIG. 8 illustrates another embodiment of a user interface for providingdrug prices from various Pharmacy Benefit Managers.

DETAILED DESCRIPTION

The disclosure provided in the following pages describes examples ofsome embodiments of the invention. The designs, figures, and descriptionare non-limiting examples of some embodiments of the invention. Otherembodiments of the system may or may not include the features disclosedherein. Moreover, disclosed advantages and benefits may apply to onlysome embodiments of the invention, and should not be used to limit thescope of the invention.

Health care costs in the United States have risen dramatically over thepast several decades. To reduce such costs, Pharmacy Benefit Managers(PBMs) have been used to process claims for prescription drug benefits.PBMs are typically entities that are independent of the benefitprovider, e.g. an insurance company, and contract with the benefitprovider to process claims for pharmacy benefits.

The distribution channels for prescription drugs are, in many cases,separated from the payment channels. For example, a patient may bediagnosed by a physician as having a condition that requires medication.The physician then decides on a drug appropriate for treatment of thediagnosed condition and prepares a prescription for an appropriate drug.The patient then takes the prescription to a pharmacy for dispensing ofthe prescription drugs. If the patient has a prescription drug benefit,e.g., through health insurance coverage, the pharmacist will utilizetheir computer system to access the PBMs computer system to apply thenegotiated charge. Consequently, the patient may not be aware of thediffering costs for the drug by different PBMs and/or at differentpharmacies.

Furthermore, different PBMs operate under different agreements withpharmacies. For example, the price for a drug associated with one PBMcan often differ significantly with respect to a second PBM.Accordingly, one PBM may provide a lower cost on one drug than otherPBMs, but have a much higher cost for other drugs. Indeed, prices forthe same drugs can vary significantly among different PBMs. Some PBMsalso offer discount cards that enable a consumer to access their rateagreements with a pharmacy. These discount cards have consumer pricesthat differ by drug and by pharmacy, and even different discount cardsfrom the same PBM can have different consumer prices.

Many Americans assume that the solution is simply to obtain pay forhealth insurance or Medicare, and thereby utilize a particular PBM, andthen show up at any pharmacy counter. While this may have been trueyears ago, it is no longer reality. Insurance companies are increasingprescription drug deductibles and patient co-pays while reducing thenumbers and quantities of the drugs that they will pay for. Meanwhile,hundreds of medicines can be purchased for cash for less than aninsurance co-pay.

In order to address these and other challenges, a system according tocertain aspects of the disclosure provides drug pricing information frommultiple PBMs to users. For example, the system may obtain, calculate,and/or estimate drug prices that are available under contracts oragreements between PBMs and various pharmacies. These prices may beprices of drugs for purchase at the various pharmacies. The system canprocess the drug pricing information such that it can be readilyprovided to users in response to requests for prices of particulardrugs. In response to such requests, the system can display relevantprices. For example, the system displays a price for each pharmacy chainand/or displays prices for a particular geographical area. The users cancompare the prices for a particular drug and determine which pharmacythey would like to purchase the drug from. The system can provide adiscount coupon that allows the users to purchase the drug at the pricelisted by the system at the selected pharmacy.

The system can aggregate drug pricing information from multiple PBMs andpresent the data to the users in a simple and easy-to-digest manner. Assuch, the system can provide users with convenience and valuableinformation that can translate into savings in time and costs.

In one embodiment of the inventive system, the system identifies thelower-cost pharmacy for a particular drug. A user enters informationabout a prescription such as the name of the drug (generic orbrand-name), the form and the dosage. The user also provides a location(city, state or ZIP), and the system identifies the prices the user canobtain at both local and mail order pharmacies for a variety of dosagesand quantities for that prescription.

The system searches the fee schedules associated with multiple PBMdiscount cards to identify lower-cost prices. Because differentpharmacies accept different discount cards and offer different consumerprices on those discount cards, the system identifies which pharmacieswill accept discount cards with the more advantageous cost savings. Thesystem then offers discount cards, presented to the user as freediscount coupons that are printable, as well as available for use on amobile device, from a variety of providers which gives the user accessto the PBM discounted prices. The discount coupon identifies therelevant PBM and the associated price.

In one embodiment, the system contracts with multiple PBMs such that thesystem can pass the PBM savings onto the users. The users do not need tocontract directly with the PBMs. Rather, the system is associated withmultiple PBMs and prints the appropriate PBM discount coupon that a usercan print and provide to a particular pharmacy.

In one embodiment, the system works with multiple discount drug cardproviders that issue a discount card that provides access to pharmacydiscounts at retail pharmacies. The system calculates the price for aparticular drug, dosage, form, or quantity at a given pharmacy usingeach of the discount cards. It does this either by performing a mockadjudication of a claim, or by calculating the price based on pricingrules, such as discount from lists such as Average Wholesale Price(“AWP”), or Maximum Allowable Cost (“MAC”) lists.

The system typically then displays the lowest price among the set ofmultiple discount cards, allowing the system to provide lower pricesthan existing discount card products. The system, in turn, receivescompensation from the discount drug card providers for prescription drugfills that take place using a particular card.

The system typically shows consumers the drug card with the lowestconsumer price. In many cases though, multiple cards will providesimilar consumer prices, even though the compensation paid by thediscount card providers to the system may differ substantially. In orderto maximize revenue, the system ranks different cards such that for thesame consumer price, there is an order in which they are displayed.

In addition, an administrator can specify an offset, such that if anoffset were set at 0.10, the higher ranked card would be displayedversus a lower ranked card as long as the consumer price for the higherranked card was no more than 0.10 higher than the lower ranked card.

FIG. 1 illustrates an overview of an example system 100 for providingdrug prices from multiple Pharmacy Benefit Managers 190, according toone aspect of the disclosure. The system 100 may be configured toprovide drug pricing information from multiple PBMs 190. The system 100may communicate with multiple PBMs 190, for example, in order to obtaininformation relating to prices of various drugs. As explained above, aPBM 190 may administer and/or process claims relating to drugs (e.g.,prescription drugs). A PBM 190 may negotiate with one or more pharmaciesregarding prices for various drugs (e.g., under a contract or agreementwith a pharmacy). For example, PBM 1 and Pharmacy A can form anagreement on how much PBM 1 will compensate Pharmacy A for certain drugsand/or how much Pharmacy A will charge customers for certain drugs.

A pharmacy generally contracts with multiple PBMs 190 for prices forvarious drugs. A pharmacy may be a part of a pharmacy chain that owns oris associated with multiple locations. For example, large pharmacychains like CVS, Walgreens, Rite-Aid, etc. have multiple retaillocations across the U.S. In such case, the pharmacy chain generallycontracts with the PBMs 190 for drug prices, and the retail locations ofthe pharmacy chain use the prices under the contract.

A PBM 190 generally administers and processes claims associated with ahealth insurance plan, such as Anthem, Aetna, etc. For example, a PBM190 and a pharmacy determines under an agreement what the price for aparticular drug will be for a health plan. The members of the healthplan are charged a certain price for the drug under the agreementbetween the PBM 190 and the pharmacy. Often, as part of the agreementbetween the PBM 190 and the pharmacy, the PBM 190 may also negotiatedrug prices for people who are not members of the health plan. Thesecustomers are unfunded because the health plan is not paying for thesecustomers for their prescriptions. These customers may be referred to as“unfunded group” to facilitate explanation. Prices for unfunded groupunder agreements between PBMs 190 and pharmacies may be referred to as“unfunded drug prices.”

Although the unfunded group may not get the benefit of the pricesavailable to members of the health plan, the unfunded drug prices maystill be much less than drug prices cash customers pay. “Cash customers”may refer to customers who purchase a drug without any discountedpricing (e.g., available through a health plan), and the prices the cashcustomers pay may be referred to as “cash prices.” The unfunded drugprices may be available through a pharmacy discount card or a discountcard. Such discount cards may provide discounts on prescription drugsand/or generic drugs. In certain embodiments, the system 100 can obtainand provide information about unfunded drug pricing under variouscontracts between PBMs 190 and pharmacies.

A PBM 190 can administer one or more networks 195 within the PBM 190. A“network” may refer to one particular set of prices. For example, apharmacy can have multiple networks 195 within the PBM 190. In suchcase, the pharmacy may have one set of prices with the PBM 190 under onenetwork and another set of prices with the PBM 190 under a differentnetwork. The price for the same drug may be different from one set ofprices to another set of prices.

An entity associated with the system 100 may negotiate and enter into anagreement with a PBM 190, which is separate from the agreements betweenthe PBM 190 and pharmacies, in order to access prices between the PBM190 and pharmacies. For example, the entity may obtain or determineunfunded drug prices under various agreements between the PBM 190 andthe pharmacies. In some cases, the prices available to the entity underthe separate agreement with the PBMs 190 may not be the exact pricesagreed upon by PBMs 190 and pharmacies, but similar prices. In suchcase, the system 100 may provide users with prices that are similar orclose to the prices agreed upon between the PBMs 190 and the pharmacies.

The system 100 may also communicate with other entities 180, such as apharmacy. For example, the system 100 can obtain drug pricinginformation from a particular pharmacy. In some embodiments, the system100 processes prescription drug claims and may communicate with apharmacy's system. In certain embodiments, some of the functionsprovided by the system 100 are integrated into an electronic medicalrecord (EMR) system, and the system 100 may communicate with the EMRsystem.

The system 100 can provide a user interface to receive input from a userand/or to display information to the user. For example, the user canenter information for obtaining drug pricing information through theuser interface. The user interface can display drug pricing informationand/or other information to the user. The user interface may be providedon various computing devices, such as a mobile phone 111, a computer112, a tablet 113, a laptop 114, etc.

FIG. 2 illustrates an example data flow diagram for providing drugprices from multiple Pharmacy Benefit Managers, according to one aspectof the disclosure. FIG. 2 illustrates a system 200 that can beconfigured to provide drug prices from multiple PBMs. The system 200 maybe similar to the system 100 in FIG. 1.

The system 200 can communicate with the systems of PBMs. For example,the system 200 communicates with the PBM 1 system 290 a and the PBM 2system 290 b. Such communication may occur through an interface, such asan application programming interface (API). The system 200 can includeone or more components that may be configured to provide drug pricesfrom multiple PBMs. For example, in FIG. 2, the system 200 includes aPBM Module 250 that can perform or execute functions relating toproviding drug prices from multiple PBMs. The system 200 may include oneor more other components as appropriate in order to implement thefunctionality of providing drug prices from multiple PBMs. The system200 may also include one or more databases 220 to store the drug pricinginformation. Any component and/or module of the system 200 can reside onone computing device or on separate computing devices.

FIG. 2 illustrates several data flow steps. Data flow steps are numberedfor illustrative purposes and can occur or be performed in any order.One or more data flow steps may be omitted depending on the embodiment,and additional data flow steps can be added depending on the embodiment.All embodiments described in this disclosure may be implementedseparately, together, or in combination. For example, one embodiment mayinclude certain features of another embodiment. In addition, certainfeatures discussed with respect to a particular embodiment may beomitted, and an embodiment may include additional features.

At data flow step 1, the system 200 obtains drug pricing informationfrom a PBM system 290. As explained above, a PBM can negotiate andcontract with one or more pharmacies on prices for various drugs. Forexample, PBM 1 and Pharmacy A agree that the price for Drug A is $20 andDrug B is $30. In some embodiments, a PBM administers multiple networks,and a pharmacy may have different price arrangements with the PBM undereach network. For instance, PBM 1 administers claims for Network 1 andNetwork 2, and the price for Drug A for Pharmacy A under Network 1 is$20 and the price for Drug A for Pharmacy A under Network 2 is $15. Incertain embodiments, the drug price information the system 200 obtainsis unfunded drug prices. The price for Drug A for unfunded group mightbe $50, compared to $20 for members of a health plan.

The system 200 can obtain information relating to negotiated drug pricesbetween a PBM and one or more pharmacies from the PBM system 290. Theseprices can be prices for purchase of various drugs at the one or morepharmacies. The system 200 may obtain the drug pricing informationthrough an API. The PBM system 290 may provide an API, which includesfunctions that can be called by the system 200. The system 200 can callvarious functions to obtain relevant information. The system 200 may beable to perform mock adjudication of claims using the API in order tofigure out drug prices charged by particular pharmacies. A mockadjudication can be performed by submitting information relating to drugname, form, dosage, quantity, pharmacy, etc. The National Drug Code(NDC) may be submitted for mock adjudication. The NDC can refer to acode that is used to identify a drug based on manufacturer, strength,package size, etc. The system 200 may try to determine the NDC for adrug at a particular pharmacy or pharmacy chain to submit for mockadjudication. In one embodiment, the system 200 submits the NDC of thedrug, the quantity of the drug, and pharmacy information to the mockadjudication API, and the API returns the price for the drug.

In some cases, the system 200 may have access to actual claims data anddetermine the prices by analyzing the claims data. By analyzing theclaims data, the system 200 can determine how much a pharmacy generallycharges for a certain drug, form, dosage, quantity, with a particularPBM.

In some embodiments, the system 200 may not obtain drug pricinginformation from a PBM, but estimate or calculate the drug prices for aparticular pharmacy with that PBM. In one example, a PBM provides a setof pricing rules for determining the price of various drugs. The pricingrules may be based on Average Wholesale Price (AWP). For instance,pricing rules may state that the price of a brand name drug isAWP−20%+dispensing fee and the price of a generic drug isAWP−70%+dispensing fee. Dispensing fee may refer to a fee associatedwith providing a drug (e.g., filling a prescription). The AWP data canbe published by and available from third parties. The PBM may alsoprovide a list of prices called the Maximum Allowable Cost (MAC) list.The MAC list can indicate maximum amounts the PBM pays for brand namedrugs and generic drugs, and the prices in the MAC list may beexceptions to the pricing rules. The system 200 can calculate the priceof a drug according to the pricing rules, compare it to the price in theMAC list, and provide lower of the two prices. Pricing rules may vary bypharmacy. If a pharmacy has more than one network with a PBM, thepricing rules can differ for each network with the PBM.

In certain embodiments, the system 200 can receive drug prices fromsources other than PBMs. In one example, the system 200 receives theinformation directly from a source, such as a pharmacy. For instance, apharmacy chain provides a list of the drug prices to the system 200.

In one embodiment, the system 200 obtains usual and customary (U&C)prices for drugs from various sources. A U&C price may refer to a cashprice for a drug at a pharmacy. The system 200 can provide U&C pricesfor a drug, for example, when prices for the drug under agreementsbetween the PBMs and pharmacies are not available. For instance, if apharmacy does not have an unfunded price for a drug under an agreementwith a PBM, the system 200 can display the pharmacy's U&C price for thedrug instead.

At data flow step 2, the system 200 processes pricing information fromthe PBMs. In some embodiments, the system 200 obtains the informationfrom the PBM systems 290 through an API, but the process of requestingand receiving the information may not be fast enough for real-timeaccess. In such case, the system 200 may cache the drug pricinginformation, e.g., in the database 220. In one example, the mockadjudication results from the PBM API are stored in the database 220.The information processed by the system 200 can be stored in thedatabase 220. FIG. 2 shows one database for illustrative purposes, butthe system 200 can include two more databases.

In some embodiments, the pricing information obtained or determined atdata flow step 1 may be stored in the database 220 prior to or withoutany processing by the system 200. For example, the system 200 may storeany raw data before formatting or transforming the data according to therequirements of the system 200. In other embodiments, the system 200 maynot perform any further processing with respect to the informationobtained at data flow step 1.

At data flow step 3, the system 200 receives a request for drug pricinginformation from the user interface 210. The user interface 210 can beprovided on a computing device or a display associated with thecomputing device. The computing device can be, for example, a mobilephone 111, a computer 112, a tablet 113, a laptop 114, etc. as shown inFIG. 1. The user may enter information relating to a drug (e.g., drugname) in the user interface 210, and the associated computing device cangenerate and send a request for drug pricing information to the system200. The user interface 210 may be a web interface, a mobileapplication, or any other appropriate form of user interface.

The request can include any information identifying a drug that the useris interested in finding out prices for. For example, the request caninclude the name of a drug, and the user enters the name of the drug inthe user interface 210. In one embodiment, the user clicks on anadvertisement for a particular drug that links to the user interface210, and the user interface 210 provides the name of the drug withoutthe user having to enter the name. The request may also include locationinformation. Some examples of location information include a zip code,city, address, etc. The location information can be information that thesystem 200 can use to narrow down the prices to those that are morerelevant to a specific geographical area. The user may enter thelocation information in the user interface 210. In some embodiments, thelocation information can be determined based on other factors, such asan IP address, with or without user input.

The system 200 can search for or determine one or more prices for therequested drug. The prices may be prices from one or more pharmaciesprovided under agreements with different PBMs as obtained or determinedat data flow step 1 and/or processed at data flow step 2. In someembodiments, the system 200 refers to the drug pricing information inthe database 220 to provide relevant prices to the user. As explainedwith data flow steps 1 and 2, the drug pricing information may have beenobtained through APIs provided by the PBMs and stored in the database220. The drug pricing information could also have been extracted fromanalyzing actual claims data. Or the drug pricing information may havebeen calculated from pricing rules or estimated in other ways. In otherembodiments, the system 200 obtains or determines the prices when arequest from the user interface 210 is received. For instance, theprices are calculated according to the pricing rules when the request isreceived. Various methods of obtaining and/or determining prices,including the methods mentioned above, can be used together, separately,or in some combination. Information relating to prices or used indetermining prices may be obtained or updated on demand (e.g., inreal-time), periodically (e.g., on a regular basis, at a fixed interval,at a variable interval, etc.), etc. For example, the system 200 canobtain drug pricing information through the API, e.g., on a daily basisor as requested. In another example, the system 200 can obtain the AWPfrom a third party source, e.g., on a weekly basis. The system 200 mayalso receive new pricing rules or updates to pricing rules periodically(e.g., every month).

In one embodiment, requests for drug pricing information are receivedand stored in a queue. Some drug prices are obtained through the APIfrom the PBM, but the speed of API may not be fast enough to provide thedrug prices in real-time. In such case, the drug prices are cached. Thefirst time a request is received for a specific drug, for example, forthat day, the prices are obtained from the API and stored in the cache.For subsequent requests, the prices are provided from the cache.

At data flow step 4, the system 200 displays drug pricing informationfrom PBMs in the user interface 210. The system 200 may display a listof prices for the drug for which pricing information was requested atdata flow step 3. The system 200 can display prices from one or morepharmacies with multiple PBMs. As explained above, in general, apharmacy contracts with multiple PBMs, and PBMs contract with multiplepharmacies for drug prices. Therefore, a pharmacy or a pharmacy chainmay have multiple prices available for the same drug. In one embodiment,the system 200 displays prices from one or more pharmacies and displaysmultiple prices for each pharmacy.

In other embodiments, the system 200 displays prices for multiplepharmacies and displays one price for each pharmacy. For instance, thesystem 200 displays the lowest price for each pharmacy. In one example,Pharmacy A has a price for Drug A with PBM 1 and another price for DrugA with PBM 2. Supposing the price for Drug A with PBM 1 is $25 and theprice for Drug A with PBM 2 is $15, the system 200 would display theprice with PBM 2 since it is lower. Displaying the lowest priceavailable from a pharmacy from multiple PBMs can be beneficial to theusers since savings can be maximized. If there are two or more samelowest prices, the system 200 may select one to display arbitrarily orbased on a variety of factors.

The prices displayed in the user interface 210 may be the prices for themost commonly purchased package of the drug. A drug can be manufacturedand packaged in different ways. For instance, the same drug can beprovided in different form (e.g., tablet, capsule, etc.), dosage (e.g.,10 mg, 20 mg, 40 mg), quantity (e.g., 10, 20, 50, etc.), etc. Form mayrefer to how the drug is delivered. Some examples of form includetablet, capsule, solution, tube, pump, etc. Dosage may refer to theamount of drug included in each unit or package and can indicate thestrength of the drug. The amount can be indicated by weight (e.g.,milligram (mg), gram (g), etc.), volume (e.g., milliliter (ml), etc.),etc. Quantity may refer to the number of units included in a package.The same drug may also be available as the brand version or genericversion. The user interface 210 may display various options forindicating the package of the drug, and the user can select optionscorresponding to the package of the drug that the user wants. Suchoptions can include, but is not limited to: generic vs. brand, form,dosage, quantity, etc. The system 200 can update the results to provideprices for the package of the drug selected by the user. The system 200may also display other information relating to the drug in the userinterface 210.

The system 200 can filter or narrow down the prices to be displayedbased on the location information. In one embodiment, the results can befiltered based on the zip code entered by the user. Zip code is used asone example, but any other geographical or location indicator can beused, such as an address. The system 200 displays prices associated withpharmacy locations in proximity to the zip code. For example, proximityis determined to be within a default radius from the zip code. The usercan select or adjust the radius for the pharmacy locations, and theresults are updated accordingly. For example, the user can select 5, 10,15, 20, 25 miles, etc. from the zip code. If a pharmacy has more thanone location within the radius, the user interface 210 may display oneprice for the pharmacy, and the user can click on the price or anotherlink to view information relating to the different locations. In oneembodiment, the user interface 210 displays the addresses for thedifferent locations.

In a certain embodiment, the user is not initially requested to enterlocation information. The system 200 displays prices for a drug at majorpharmacy chains without filtering the prices for a geographical area.Then, the user may enter the location information, and the userinterface 210 displays the prices relating to the location.

In some embodiments, the default or initial radius of pharmacy locationsis determined by the system 200 based on factors like populationdensity. For example, in highly populated cities like New York or LosAngeles, a smaller initial radius may be selected, for example, to avoidincluding too many results. The user can adjust the radius asappropriate in order to view prices for a larger area or a smaller area.

In certain embodiments, the system 200 displays a map of pharmacylocations within the default radius or user designated radius from thelocation information, along with the prices associated with thesepharmacy locations. The map can initially display pharmacy locations inthe default radius, and as the user changes the radius, the map can beupdated to show pharmacy locations in the changed radius. For instance,if the radius is increased, the map zooms out and displays morelocations, and if the radius is decreased, the map zooms in and displaysfewer locations.

The system 200 can create an index to reduce the amount of time forsearching for prices that are relevant to a specific location orgeographical area. In one embodiment, the system 200 creates atwo-dimensional (“2D”) geospatial index. For example, when using a 2Dgeospatial index, the prices are stored with relevant 2D geospatialpoint(s), and the prices can be queried using the 2D geospatial index.In another embodiment, the system 200 creates a three-dimensional (“3D”)geospatial index. A 3D geospatial index can have the spatial coordinatesas the x-axis and the y-axis, and have the drug price as the z-axis.

The system 200 can also filter the prices to be displayed in the userinterface 210 based on a variety of factors other than or including thelocation information. In one embodiment, the user interface 210 displaysoptions relating to pharmacies, and the user can choose which types ofpharmacies to view prices for. Some examples of pharmacy options ortypes include: 24-hour, mail order, home delivery, compounding, walk-inclinic, drive-up window, languages spoken, major chains, etc.

For a price displayed in the user interface 210, the system 200 cangenerate a discount coupon to purchase the drug at or close to thedisplayed price. A discount coupon can be for a specific pharmacy or aspecific pharmacy location. In some embodiments, the prices displayedare unfunded prices available under agreements between PBMs andpharmacies for unfunded group. The system 200 provides a discount couponin order to allow unfunded group to purchase the drug at unfundedprices.

A discount coupon for a drug can include the drug information and theprice. The drug information may be the information relating to thespecific package of the drug the user wants to purchase (e.g., name,form, dosage, quantity, etc.), as explained above. The discount couponcan include information, such as PCN number, bin number, group number,member ID, etc. PCN number and/or bin number can identify a PBM, andgroup number can identify the entity associated with the system 200.Member ID may be an identifier assigned by the system 200 under theagreement between the entity and the PBM identified by the PCN and/orbin number. In one embodiment, the member ID is used to identify theentity associated with the system 200. In another embodiment, acombination of group number and member ID is used to identify theentity. Information included on a discount coupon is explained furtherwith respect to FIG. 6.

The discount coupon can be printed, emailed, sent by text message, etc.and presented at the pharmacy associated with the price for purchase ofthe drug at that price. In certain embodiments, the actual price may notbe exactly the same as purchase price but close to the listed price. Thepharmacist can enter the PCN number, bin number, group number, memberID, or any combination thereof to provide the listed price to the user.In some embodiments, the discount coupon includes a bar code, QR code,or another form of code that can be scanned by the pharmacist. Couponscan provide access to prices that were not previously available to acustomer without the coupons. For example, discount coupons provideunfunded drug prices to customers who are not members of a healthinsurance plan covered by the agreement between a pharmacy and a PBM. Inaddition, the coupons allow customers to purchase at lower prices amongthe unfunded drug prices available from multiple PBMs.

The system 200 can also provide a discount card, in addition to discountcoupons. A user can apply for a discount card which provides access tosome or all of the prices provided by the system 200. Instead ofprinting a coupon for each price, the user can present the discountcard, which a pharmacy can have in the user's record. The discount cardthen can work in a similar fashion as an insurance card, and the usercan purchase any drugs that have unfunded prices under the PBM-pharmacyagreements at these prices. In some embodiments, a discount couponfunctions as a discount card. For example, the pharmacist at a specificpharmacy enters the discount coupon in the user's record, and the usercan access the prices provided by the system 200 for the pharmacy forsubsequent purchases.

In one embodiment, the price of the drug for the discount coupon isdynamically adjusted. For example, if the cash price for a drug at apharmacy is lower than the price of the drug provided by the system 200,the system 200 adjusts the price on the discount coupon to be lower thanthe cash price.

The system 200 may rank the drug prices from multiple PBMs prior todisplaying drug prices in the user interface 210. The system 200 maydisplay only some of the prices from the ranking process. Generally, ifa pharmacy has multiple prices for the same drug under agreements withdifferent PBMs, the system 200 displays one price for the pharmacy. Inone embodiment, the system 200 ranks the prices for a pharmacy fromlowest to highest and displays the lowest price. For example, a lowerprice is ranked higher than a higher price. In other embodiments, thesystem 200 ranks the prices for a pharmacy using methods other thanlowest to highest. The system 200 may choose to display only one pricefrom a ranking process in the user interface 210 (e.g., highest rankedor lowest ranked price from the ranking process, etc.).

In one embodiment, the system 200 may rank a higher price from one PBMas higher than, or before, a lower price from another PBM. The system200 may do so based on various factors. One such factor can beacceptance rate of a price or prices from a PBM at pharmacies. Anotherfactor can be a partnership with a particular PBM. For instance, a PBMmay provide more accurate information regarding prices or provideadditional benefits that can be passed on to consumers. The system 200may rank a higher price higher than a lower price if the differencebetween the higher price and the lower price does not exceed a thresholdvalue (or is less than the threshold value). Ranking a price higher thananother price can refer to placing the price before the other price in asequence. The threshold can be set low such that the impact on the priceto the user is minimal. For example, the threshold can be set to $0.10,$0.20, etc. In general, the threshold value is less than $1. The samethreshold value may be set for all drugs provided by a PBM, or adifferent threshold value can be set for a group of drugs or anindividual drug provided by a PBM.

The system 200 may rank prices from PBMs based on the in-storeacceptance rate of prices or coupons from a PBM at a particularpharmacy. An acceptance rate may refer to the rate at which a price or acoupon from a PBM is accepted at a specific pharmacy. The acceptancerate of a price can be affected by a variety of attributes or factors,such as format of member ID and/or group ID, programmatic blocking bypharmacies, system and/or software used by pharmacies, etc. Often, theinformation on the coupon is entered manually into the pharmacy systemby a pharmacist and can involve human error. Accordingly, prices fromPBMs that use simpler identifiers may have a higher success rate ofbeing accepted at the pharmacy locations. The identifiers can includethe member ID, group ID, bin number, PCN number, etc. By considering theacceptance rates associated with prices from a PBM, the system 200 canprovide a price that is more likely to translate into a discount for theuser.

In one example, the in-store acceptance rate of prices from PBM 1 is85%, and the in-store acceptance rate of prices from PBM 2 is 70%. Theprice for Drug A at Pharmacy A under PBM 1 is $25.10, and the price forDrug A at Pharmacy A under PBM 2 is $25. The threshold value for rankinga higher paying PBM price higher is set to $0.10. Because PBM 1 has ahigher acceptance rate, but the price differential between the PBM 1price and the PBM 2 price is $0.10 and does not exceed the thresholdvalue, the system 200 ranks the PBM 1 price higher than the PBM 2 price.The system 200 displays PBM 1 price for Pharmacy A in the user interface210.

In some embodiments, the system 200 may rank a price based on either theacceptance rate or the threshold, but not both. For example, the system200 can rank a higher price having a higher acceptance rate higher thana lower price having a lower acceptance rate without applying athreshold to the price difference (e.g., when the acceptance rate of alower price is very low). A lower price that has an acceptance rate of15% may not be as beneficial to the user as a higher price that has anacceptance rate of 95%. Or the system 200 can rank a higher price over alower price if the price difference does not exceed a threshold withoutconsidering the acceptance rate (e.g., based on another factor, such asorder of preference for PBMs).

Prices with low acceptance rates or prices not being accepted may beexcluded in the ranking process. For example, if a particular class ofdrugs is not being processed at certain pharmacies or by certain PBMs,the prices for these drugs would not be displayed even if they are lowerprices. Prices having low acceptance rates (including those not beingaccepted) may not be included in the ranking, or they may be ranked butexcluded from being displayed. The system 200 may define a thresholdvalue for acceptance rates. Prices having acceptable rates that do notmeet the threshold value (e.g., less than the threshold value, or lessthan or equal to the threshold value, depending on the embodiment) maybe excluded from ranking and may not be displayed in the user interface210. For example, if the acceptance rate threshold is 50%, and theacceptance rate of a price is 5%, the price is not included in theranking. The acceptance rate threshold value may be applied prior toranking or subsequent to ranking. For instance, the system 200 canperform the ranking and determine whether the ranked prices to bedisplayed meet the acceptance rate threshold value (e.g., whether theprices have acceptance rates that are greater than the threshold value,or greater than or equal to the threshold value, depending on theembodiment). Or the system 200 can eliminate prices that do not meet theacceptance rate threshold value (e.g., prices having acceptance ratesthat are less than the threshold value, or less than or equal to thethreshold value, depending on embodiment) before the ranking. Anacceptance rate threshold value may be defined for each drug, for agroup of drugs (e.g., particular class of drugs), for all drugs, etc.

Information relating to acceptance rates may be provided by the PBM ordetermined by the system 200. Acceptance rate information may beavailable for each drug, for a group of drugs (e.g., particular class ofdrugs), or for all drugs. In one example, the acceptance rate can beprovided for each drug. In some cases, one acceptance rate value may beprovided for all drugs (or some drugs); the PBMs may not differentiatebetween individual drugs in determining the acceptance rate. If a PBMhas multiple networks, the acceptance rate information can be providedfor each network.

In one embodiment, the system 200 compares the number of coupons printedand/or viewed and the number of in-pharmacy redemption of coupons inorder to determine the acceptance rate. If a coupon for a drug isfrequently viewed or printed by users, but has a low in-store conversionrate, this could flag that there is an issue with acceptance of theprice or coupon. For instance, the coupon for Drug A with the price fromPBM 1 at Pharmacy A may be printed or viewed 100 times, but only resultin 45 redemptions at Pharmacy A. In such case, the acceptance rate ofthe price from PBM 1 for Drug A at Pharmacy A is 45%. On the other hand,the coupon for Drug A with the price from PBM 2 at Pharmacy A may beprinted or viewed 100 times, and result in 95 redemptions at Pharmacy A.The acceptance rate of the price from PBM 2 for Drug A at Pharmacy A is95%. The acceptance rate can be based on the number of prints and/orviews and the number of redemptions for a particular period of time(e.g., monthly, biweekly, weekly, daily, etc.). The print and/or viewcount and redemption count for coupons (or prices) from different PBMsmay be available from historical data. The print and/or view count andredemption count for coupons (or prices) may also be available fromcurrent data (e.g., from the same day, week, etc.).

In certain embodiments, if there are more than two PBMs, the system 200can list the PBMs in order of preference and determine multiplethreshold values for listing one PBM over another PBM. For instance,there are three PBMs (PBM 1, PBM 2, PBM 3), and the preference forlisting prices from these PBMs are in the order of PBM 3, PBM 1, and PBM2. The system 200 defines a threshold value for listing prices from PBM3 over prices from PBM 1 and a threshold value for listing prices fromPBM 1 over prices from PBM 2. Accordingly, the system 200 can rankprices from multiple PBMs for a pharmacy, given that the pricedifference between one PBM and another PBM does not exceed thedesignated threshold.

In one embodiment, the system 200 may determine whether to rank a pricefrom one PBM higher than a price from another PBM based on thepercentage of prices to show for a specific PBM. Referring to theexample above, if there are three PBMs (PBM 1, PBM 2, PBM 3), the system200 designates a percentage of prices to display from PBM 1, apercentage of prices to display from PBM 2, and a percentage of pricesto display from PBM 3. For instance, the percentage for PBM 3 can be50%, the percentage for PBM 1 can be 30%, and the percentage for PBM 2can be 20%. In certain embodiments, the percentage for a PBM is linkedto the threshold value for listing one PBM over another. For example,the percentage for displaying prices from PBM 1 is linked to thethreshold value for listing PBM 3 over PBM 1 such that when thethreshold value is changed, the percentage is updated. If the percentageis changed, the threshold value is updated.

The system 200 can also choose to rank the prices from different PBMsbased on various factors other than or in addition to acceptance rateand PBM partnership, such as compensation by a PBM to the entity for apurchase of a drug (e.g., filling a prescription). Such ranking may sortthe prices in an order that is different from a lowest-to-highestranking.

In this manner, the system 200 can allow users to purchase drugs atprices that were not previously available to them by utilizing thediscount coupons. The entity associated with system 200 can enter intoagreements with the PBMs and pass on the savings to users. By obtainingand/or determining drug pricing information from multiple PBMs andselecting lower prices available from each PBM to provide to the users,the entity can create a new discount network of prices. The entity canalso make unfunded drug prices available to the users, which can save asignificant amount of money. Often, the cash price of a drug is multipletimes the unfunded price of the drug. Users without health insuranceplans can benefit from reduced prices almost all of the time. And evenusers with health insurance plans can benefit when a drug is not coveredunder their plans or the system 200 provides better prices for the drug.As explained above, the system 200 can provide a convenient andeasy-to-use user interface 210, making it simple for users to find theinformation they are looking for.

In some embodiments, the system 200 is integrated into an EMR system.The system 200 can provide an API that can be called by the EMR system.For example, the EMR system calls one or more functions of the API todetermine which pharmacy to send a patient's prescription to. Or the EMRsystem can present a link to a patient so that the patient can choose aspecific pharmacy location based on the drug pricing information.

The system 200 may also display other information relating to a drug inthe user interface 210. The system 200 could also provide additionalinformation that may be helpful to users. Such information is explainedin more detail with respect to FIGS. 7 and 8.

FIG. 3 illustrates one embodiment of an example process 300 fordisplaying drug prices from multiple for PBMs. The process 300 isdescribed with respect to the system 200 of FIG. 2. However, one or moreof the steps of process 300 may be implemented by other systems, such asthe system 100 described in FIG. 1. The process 300 can be implementedby any one of, or a combination of, the components of the system 200(e.g., the PBM module 250). Further details regarding certain aspects ofat least some of steps of the process 300 are described in greaterdetail above with reference to FIGS. 1 and 2.

At block 301, the system 200 provides a user interface 210 for providingdrug pricing information. Users can request pricing information about aspecific drug via the user interface 210. For example, the user canenter the name of the drug and the user's zip code in the user interface210, and send a request for pricing information.

At block 302, the system 200 receives from the user interface 210information identifying a first drug. The information can include thename of the drug. The system 200 can also receive location informationfrom the user interface 210.

At block 303, the system 200 obtains a first set of prices for the firstdrug that is associated with a first pharmacy benefit manager (PBM). APBM may process a claim relating to a drug and have an agreement with apharmacy relating to a price of one or more drugs (e.g., by a contract).The first set of prices can include at least one price for the firstdrug, and each price in the first set of prices can be determined by anagreement between the first PBM and a pharmacy. Each price in the firstset of prices may be a price for purchase of the first drug at thepharmacy associated with the price.

In one embodiment, the at least one price in the first set of prices isobtained by performing of a mock adjudication of a claim relating to thefirst drug using an API provided by the first PBM. In anotherembodiment, the at least one price in the first set of prices isobtained based on pricing rules for the first drug provided by the firstPBM.

At block 304, the system 200 obtains a second set of prices for thefirst drug that is associated with a second PBM. The second set ofprices can include at least one price for the first drug, and each pricein the second set of prices can be determined by an agreement betweenthe second PBM and a pharmacy. Each price in the second set of pricesmay be a price for purchase of the first drug at the pharmacy associatedwith the price. The pharmacy for the first set of the prices and thesecond set of prices may be the same pharmacy or different pharmacies.

In one embodiment, similar to block 303, the at least one price in thesecond set of prices is obtained by performing of a mock adjudication ofa claim relating to the first drug using an API provided by the secondPBM. In another embodiment, the at least one price in the second set ofprices is obtained based on pricing rules for the first drug provided bythe second PBM.

In some embodiments, the first PBM may administer claims relating to ahealth insurance plan, and an agreement between the first PBM and apharmacy may specify a price of the first drug for a member of thehealth insurance plan and a price of the first drug for a customer thatis not a member of the health insurance plan. The first set of pricescan include the price of the first drug for a customer that is not amember of the health insurance plan, which may be referred to as the“non-member price.”

Similarly, the second PBM may administer claims relating to a healthinsurance plan. The health insurance plan may be the same plan as or adifferent plan from the one administered by the first PBM. An agreementbetween the second PBM and a pharmacy may specify a price of the firstdrug for a member of the health insurance plan and a price of the firstdrug for a customer that is not a member of the health insurance plan.The second set of prices can include the price of the first drug for acustomer that is not a member of the health insurance plan. The pharmacymay be the same pharmacy with which the first PBM has an agreement or adifferent pharmacy from the pharmacy with which the first PBM has anagreement. In these embodiments, the system 200 may display thenon-member price for the first drug included in the first set of prices,or the non-member price for the first drug included in the second set ofprices.

At block 305, the system 200 displays in the user interface 210 at leasta portion of the first set of prices and the second set of prices. Thefirst set of prices and the second set of prices each include at leastone price for the same drug, but the system 200 may not list a pricefrom each set. For example, if the price of the first drug in the firstset and the price of the first drug in the second set are for the samepharmacy, the system 200 can list one of the prices (e.g., the lowerprice).

In one embodiment, the first set of prices includes a price for thefirst drug determined by an agreement between the first PBM and apharmacy, and the second set of prices includes a second price for thefirst drug determined by an agreement between the second PBM and thepharmacy. The system 200 compares the first price for the first drug andthe second price for the first drug, and displays lower of the firstprice for the first drug and the second price for the first drug. Inanother embodiment, as explained above, if an agreement between a PBMand a pharmacy specifies a non-member price for the first drug, thesystem 200 displays the non-member price in the user interface 210.

In some embodiments, the system 200 filters the first set of prices andthe second set of prices based on the location information prior todisplaying at least a portion of the first set of prices and the secondset of prices in the user interface 210.

The process 300 can include fewer, more, or different blocks than thoseillustrated in FIG. 3 without departing from the spirit and scope of thedescription. Moreover, it will be appreciated by those skilled in theart and others that some or all of the functions described in thisdisclosure may be embodied in software executed by one or moreprocessors of the disclosed components and mobile communication devices.The software may be persistently stored in any type of non-volatilestorage.

FIG. 4 illustrates another embodiment of an example process 400 fordisplaying drug prices from multiple for PBMs. The process 400 isdescribed with respect to the system 200 of FIG. 2. However, one or moreof the steps of process 400 may be implemented by other systems, such asthe system 100 described in FIG. 1. The process 400 can be implementedby any one of, or a combination of, the components of the system 200(e.g., the PBM module 250). Further details regarding certain aspects ofat least some of steps of the process 400 are described in greaterdetail above with reference to FIGS. 1-3.

Blocks 401 through 405 are similar to blocks 301 through 305 in FIG. 3,respectively. Details relating to blocks 401 through 405 are describedin detail with respect to FIGS. 1-3. At block 401, the system 200provides a user interface 210. At block 402, the system 200 receivesinformation input in the user interface 210. At block 403, the system200 obtains a first set of prices for the first drug that is associatedwith a first PBM. At block 404, the system 200 obtains a second set ofprices for the first drug that is associated with a second PBM. At block405, the system 200 displays in the user interface 210 at least aportion of the first set of prices and the second set of prices.

At block 406, the system 200 receives a selection of a price from one ormore prices displayed in the user interface 210. For example, the usercan select a price among the prices displayed in the user interface 210.

At block 407, the system 200 generates a discount card or coupon thatprovides access to the selected price for a purchase of the first drugat a pharmacy associated with the selected price. Without the discountcard or the discount coupon, the selected price from a PBM associatedwith the selected price may not available to a customer for the purchaseof the first drug at the pharmacy. The discount card or the discountcoupon can include an identification number that is recognized by thePBM associated with the selected price. The selected price can beprovided under an agreement between an entity associated with the system200 and the PBM associated with the selected price, where this agreementis different from an agreement between the PBM associated with theselected price and the pharmacy associated with the selected price.

In one embodiment, if an agreement between a PBM and a pharmacyspecifies a price of the first drug for customers who are not members ofa health insurance plan, the system 200 displays in the user interface210 the price of the first drug for non-member customers. If the userselects the non-member price in the user interface 210, the system 200generates a discount coupon for the purchase of the first drug at thenon-member price at the pharmacy.

The process 400 can include fewer, more, or different blocks than thoseillustrated in FIG. 4 without departing from the spirit and scope of thedescription. Moreover, it will be appreciated by those skilled in theart and others that some or all of the functions described in thisdisclosure may be embodied in software executed by one or moreprocessors of the disclosed components and mobile communication devices.The software may be persistently stored in any type of non-volatilestorage.

FIG. 5 illustrates one embodiment of an example process 500 for rankingdrug prices from multiple for PBMs. The process 500 is described withrespect to the system 200 of FIG. 2. However, one or more of the stepsof process 500 may be implemented by other systems, such as the system100 described in FIG. 1. The process 500 can be implemented by any oneof, or a combination of, the components of the system 200 (e.g., the PBMmodule 250). Further details regarding certain aspects of at least someof steps of the process 500 are described in greater detail above withreference to FIGS. 1-4.

Blocks 501 through 504 are similar to blocks 301 through 304 in FIG. 3and blocks 401 through 404 in FIG. 4, respectively. Details relating toblocks 501 through 504 are described in detail with respect to FIGS.1-4. At block 501, the system 200 provides a user interface 210. Atblock 502, the system 200 receives from the user interface 210information identifying a first drug. At block 503, the system 200obtains a first set of prices for the first drug that is associated witha first PBM. At block 504, the system 200 obtains a second set of pricesfor the first drug that is associated with a second PBM. The first setof prices can be determined by an agreement between the first PBM and apharmacy, and the second set of prices can be determined by an agreementbetween the second PBM and a pharmacy. The pharmacy for the first set ofthe prices and the second set of prices may be the same pharmacy ordifferent pharmacies.

At block 505, the system 200 ranks the at least one price for the firstdrug in the first set of prices for the first drug and the at least oneprice for the first drug in the second set of prices for the first drugin an order that is different from lowest to highest.

The system 200 may determine that the at least one price for the firstdrug in the first set of prices is higher than (or equal to) the atleast one price for the first drug in the second set of prices, but rankthe at least one price in the first set of prices higher than the atleast one price in the second set of prices. In one embodiment, thesystem 200 may rank the at least one price in the first set of priceshigher than the at least one price in the second set of prices based onan acceptance rate associated with the at least one price in the firstset of prices and an acceptance rate associated with the at least oneprice in the second set of prices. An acceptance rate may refer to therate at which a price or prices provided by a PBM are accepted at aparticular pharmacy. If a pharmacy has multiple networks with a PBM, theacceptance rates can differ for each network. Acceptance rateinformation may be available per drug, per group of drugs, for all drugsin a network, etc. The system 200 may rank the higher price higher whenthe difference between the at least one price for the first drug in thefirst set of prices and the at least one price for the first drug in thesecond set of prices does not exceed a threshold value. For example, thethreshold value can be a very small number to minimize any impact on thecustomer price for the drug. Examples of the threshold value include$0.10, $0.20, amounts under $1, etc. The system 200 generally displaysthe higher ranked price from the ranking process in the user interface210.

The system 200 may also specify a preferred order for ranking pricesfrom the first PBM and prices from the second PBM. The preferred ordercan indicate that prices from the first PBM are to be ranked higher thanprices from the second PBM. In general, higher ranked prices have ahigher level of importance or priority. For example, higher rankedprices list may appear first in a sequence.

In one embodiment, the system 200 determines share of prices to displayfrom a certain PBM by designating percentages for different PBMs. Forexample, the system 200 can determine a first percentage that indicatesa portion of prices from the first PBM to be displayed in the userinterface 210 and a second percentage that indicates a portion of pricesfrom the second PBM to be displayed in the user interface 210. Theranking can be performed by ranking the at least one price for the firstdrug in the first set of prices and the at least one price for the firstdrug in the second set of prices based at least in part on the firstpercentage and the second percentage. A percentage may be linked to athreshold value for ranking prices from one PBM over another PBM suchthat adjusting the percentage adjusts the threshold value and adjustingthe threshold value adjusts the percentage.

At block 506, the system 200 displays a price from the ranking in theuser interface 210. For example, the highest ranked price may be listedfor a specific pharmacy. The user can select a displayed price, forexample, to purchase a drug at the selected price. In one embodiment,the system 200 generates a discount card or coupon that provides accessto the selected price for the purchase of the first drug at a pharmacyassociated with the selected price.

The process 500 can include fewer, more, or different blocks than thoseillustrated in FIG. 5 without departing from the spirit and scope of thedescription. Moreover, it will be appreciated by those skilled in theart and others that some or all of the functions described in thisdisclosure may be embodied in software executed by one or moreprocessors of the disclosed components and mobile communication devices.The software may be persistently stored in any type of non-volatilestorage.

FIG. 6 illustrates one embodiment of a discount coupon 600. Detailsrelating to the discount coupon are explained in more detail withrespect to FIGS. 1-5. Various functions relating to the discount coupon600 can be performed by the system 100 described in FIG. 1, the system200 described in FIG. 2, or any other appropriate system. The discountcoupon 600 can be for a specific drug and may include informationrelating to the drug 610. Drug information 610 may include the name ofthe drug 611, the form of the drug 612, the dosage of the drug 613, thequantity of the drug 614, etc. The name of the drug 611 can be thegeneric name or the brand name. In the example of FIG. 6, the genericname of the drug 611 is atorvastatin; the form of the drug 612 is atablet; the dosage of the drug 613 is 20 mg; and the quantity of thedrug 614 is 30.

The coupon 600 may also include the price for the drug 620 for aparticular pharmacy 640. A pharmacy chain may have multiple locationswithin a geographical area of interest, and in such case, the coupon 600can indicate a particular pharmacy location. In FIG. 6, the pharmacy isa Target pharmacy, and the pharmacy location is at 2300 Park Avenue,Tustin, Calif. The listed price 620 for the package of the drugdesignated by the drug information 610 is $15.14.

The discount coupon 600 may also include the member ID 631, group number632, bin number 633, and PCN number 634, which may be referred tocollectively as “pharmacist info” 630. The pharmacist info 630 may beentered by a pharmacist at a pharmacy for the purchase of the drug. Asexplained above, the member ID 631 may be an identifier assigned by thesystem 200 under an agreement between the entity associated with thesystem 200 and the PBM the price 620 is provided by. A unique orrotating member ID can be assigned to a specific user. The group number633 can identify the entity associated with the system 200. The binnumber 633 and/or the PCN number 634 can identify the PBM. In oneembodiment, the member ID 631 is used to identify the entity associatedwith the system 200. In another embodiment, a combination of the memberID 631 and the group number 632 is used to identify the entity. In theexample of FIG. 6, the member ID 631 is “01GR904059900000”; the group ID632 is “06340001”; the bin number 633 is “600428”; and the PCN number634 is “05100000.”

The discount coupon 600 can include other information, such as a phonenumber for a help line, a phone number for pharmacists, etc. A discountcard may include similar information other than a particular pharmacysince discount cards can be accepted at multiple pharmacies.

FIG. 7 illustrates one embodiment of a user interface 700 for providingdrug prices from various PBMs. Details relating to the user interface700 are explained in more detail with respect to FIGS. 1-6. Variousfunctions relating to the user interface 700 can be performed by thesystem 100 described in FIG. 1, the system 200 described in FIG. 2, orany other appropriate system. The user interface 700 is provided toreceive information relating to a drug from a user. The user interface700 may be a web user interface. The user interface 700 can include asection for entering the drug information 710. In one embodiment, thesection 710 includes an input field for drug name 711 and an input fieldfor location 712. The section 710 also includes a button 713 forgenerating a request for pricing information for the drug name 711entered by the user. The drug name field 711 can display the name of acommon drug as a suggestion to provide users with some guidance onentering drug names. In one embodiment, the user can enter a healthcondition (e.g., asthma) in the drug name field 711 to view prices fordrugs related to the health condition. In some embodiments, as the usertypes the drug name, the drug name field 711 shows a list of drug namesthat include the typed letters and/or shows related drug names orconditions for the entered drug name. The location input field 712 canaccept various types of input, such as city, zip code, address, etc.

The example user interface 700 in FIG. 7 may also include various menuitems. Some examples include a menu item for downloading a mobileapplication for requesting drug prices from the system 200, a menu itemfor applying for a discount card, a menu item for registering to becomeof a member of the system 200, and a menu item for signing in forregistered members. The system 200 can store information for registeredmembers, such as drugs purchased by members using discount couponsprovided by the system 200. The system 200 can also provide additionalfeatures, such as providing price alerts, prescription fill alerts, etc.

FIG. 8 illustrates another embodiment of a user interface 800 forproviding drug prices from various PBMs. Details relating to the userinterface 800 are explained in more detail with respect to FIGS. 1-7.Various functions relating to the user interface 800 can be performed bythe system 100 described in FIG. 1, the system 200 described in FIG. 2,or any other appropriate system. The user interface 800 is provided todisplay drug prices and/or information relating to a specific drug. Asexplained with respect to FIG. 7, the user may enter the drug name andthe location information and send a request for pricing information fora specific drug. In response to the request, the user interface 800 canprovide drug prices for the drug. The user interface 800 may displaydrug information 810, such as the name of the drug 811, the form of thedrug 812, the dosage of the drug 813, the quantity of the drug 814, etc.The name of the drug 811 can be the generic name, brand name, or both.The drug information 810 can be for a specific package of the drug(e.g., the most common package).

When there is more than one type of package available for a drug, theuser interface 800 can display various options for indicating aparticular package of the drug. For example, the system 200 can provideoptions for generic or band version 811, options for form 812, optionsfor dosage 813, options for quantity 814, etc. The user can select anappropriate option for each category to select the package of the drugthat the user wants. In the example of FIG. 8, atorvastatin is availableas generic or brand version, and the generic name and the brand name ofthe drug are provided as options for the drug name 811. The only optionfor form 812 is tablet. The options for dosage 813 are 10 mg, 20 mg, 40mg, and 80 mg. The options for quantity 814 are 15 tablets, 30 tablets,45 tablets, 60 tablets, and 90 tablets. The user interface 800 alsoprovides an input field for entering a desired quantity 814. The optionscorresponding to the package for which the prices are currentlydisplayed are selected under each category. In this example, the prices820 are for the generic version atorvastatin in tablet form having 20 mgdosage in quantity of 30 tablets, and these options are marked in theuser interface 800. The user can select any of the options providedunder each category to designate a combination of options that the useris interested in.

The user interface 800 may also display prices 820 for the drugavailable from one or more pharmacies. The prices 820 may be for themost common or user selected package for the drug. In one embodiment,the user interface 800 displays a default number of prices, and if thereare any additional prices not displayed, provides a link or a button toshow the additional prices. In the example of FIG. 8, each price 820 isassociated with one pharmacy. If there is more than one price for eachpharmacy, the multiple prices for the pharmacy may have been rankedaccording to a lowest to highest algorithm or another ranking method asdiscussed above. The system 200 can display one price for each pharmacy,for example, the highest ranked price. The price 820 for Walmart is$15.14 with a discount coupon. The price 820 for Target is also $15.14with a discount coupon. The price 820 for HealthWarehouse, an onlinepharmacy, is $16.00 without a discount coupon, and so on. In the exampleof FIG. 8, the prices 820 from different pharmacies are listed in theorder of lowest to highest. For a price 820 that is available through adiscount coupon, the user interface 800 displays a button 830 forobtaining a discount coupon for that price 820. The coupon can beaccepted at the pharmacy associated with the price 820. Details relatingto the coupon are explained in more detail with respect to FIGS. 1-7.

In some embodiments, the user may not see a price 820 listed for apharmacy of the user's interest, and the system 200 provides a genericdiscount coupon that can be used at pharmacies not listed in the userinterface 800. Such pharmacies may be independent pharmacies notassociated with large pharmacy chains. PBMs may provide prices for suchindependent pharmacies to the entity associated with the system 200.

The user interface 800 can also display the location information 840relating to the prices 820. The location information 840 can be enteredby the user. The user interface 800 may also indicate the default radius841 for including pharmacy locations relating to the locationinformation 840. In FIG. 8, the default radius 841 is listed as 4 miles.The user can change the radius 841 as appropriate. For example, the usercan select from a list of options in a drop-down menu. The user may beable to change the location information 840 after the prices 820 areinitially displayed, and the displayed prices 820 can change based onthe location information 840. The user interface 800 can provide aninput field for entering a new city, zip code, address, etc. The userinterface 800 may also provide a map 845 showing a region that includesthe pharmacy locations for the prices 820 displayed in the userinterface 800. As the user updates the location information 840 or thedefault radius 841, the map 845 can change to reflect the updatedinformation.

The user interface 800 may also display pharmacy options 850. Asexplained above, the user can choose which types of pharmacies to viewprices for. Some examples of pharmacy options or types include: 24-hour,mail order, home delivery, compounding, walk-in clinic, drive-up window,languages spoken, major chains, etc.

The example user interface 800 in FIG. 8 may also include other types ofinformation relating to the drug, such as a description of the drug,side effects, images of the drug, news relating to the drug,advertisements relating to the drug, etc. The user interface 800 canalso provide other useful information, such as savings tips.

The various illustrative processes described herein may be implementedas electronic hardware, computer software, or combinations of both. Toclearly illustrate this interchangeability of hardware and software,various illustrative components, blocks, modules, and states have beendescribed above generally in terms of their functionality. However,while the various modules are illustrated separately, they may sharesome or all of the same underlying logic or code. Certain of the logicalblocks, modules, and processes described herein may instead beimplemented monolithically.

The various processes described herein may be implemented or performedby a machine, such as a computer, a processor, a digital signalprocessor (DSP), an application specific integrated circuit (ASIC), afield programmable gate array (FPGA) or other programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof designed to perform the functions described herein.A processor may be a microprocessor, a controller, microcontroller,state machine, combinations of the same, or the like. A processor mayalso be implemented as a combination of computing devices, e.g., acombination of a DSP and a microprocessor, a plurality ofmicroprocessors or processor cores, one or more graphics or streamprocessors, one or more microprocessors in conjunction with a DSP, orany other such configuration.

The processes described herein may be embodied directly in hardware, ina software module executed by a processor, or in a combination of thetwo. For example, each of the processes described above may also beembodied in, and fully automated by, software modules executed by one ormore machines such as computers or computer processors. A module mayreside in a computer-readable storage medium such as RAM memory, flashmemory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, aremovable disk, a CD-ROM, memory capable of storing firmware, or anyother form of computer-readable storage medium known in the art. Anexemplary computer-readable storage medium can be coupled to a processorsuch that the processor can read information from, and write informationto, the computer-readable storage medium. In the alternative, thecomputer-readable storage medium may be integral to the processor. Theprocessor and the computer-readable storage medium may reside in anASIC.

Depending on the embodiment, certain acts, events, or functions of anyof the processes or algorithms described herein can be performed in adifferent sequence, may be added, merged, or left out all together.Thus, in certain embodiments, not all described acts or events arenecessary for the practice of the processes. Moreover, in certainembodiments, acts or events may be performed concurrently, e.g., throughmulti-threaded processing, interrupt processing, or via multipleprocessors or processor cores, rather than sequentially.

Conditional language used herein, such as, among others, “can,” “could,”“might,” “may,” “e.g.,” and from the like, unless specifically statedotherwise, or otherwise understood within the context as used, isgenerally intended to convey that certain embodiments include, whileother embodiments do not include, certain features, elements and/orstates. Thus, such conditional language is not generally intended toimply that features, elements and/or states are in any way required forone or more embodiments or that one or more embodiments necessarilyinclude logic for deciding, with or without author input or prompting,whether these features, elements and/or states are included or are to beperformed in any particular embodiment.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it will beunderstood that various omissions, substitutions, and changes in theform and details of the logical blocks, modules, and processesillustrated may be made without departing from the spirit of thedisclosure. As will be recognized, certain embodiments of the inventionsdescribed herein may be embodied within a form that does not provide allof the features and benefits set forth herein, as some features may beused or practiced separately from others.

What is claimed is:
 1. A method of displaying prices for drugs from aplurality of pharmacy benefit managers, the method comprising: providinga user interface using a computer processor; receiving informationidentifying a first drug from the user interface; obtaining a first setof prices for the first drug that is associated with a first pharmacybenefit manager (PBM), wherein a pharmacy benefit manager processes aclaim relating to a drug and has an agreement with one or morepharmacies relating to a price of one or more drugs, the first set ofprices comprising at least one price for the first drug and each pricein the first set of prices being determined by an agreement between thefirst PBM and a pharmacy; obtaining a second set of prices for the firstdrug that is associated with a second pharmacy benefit manager, thesecond set of prices comprising at least one price for the first drugand each price in the second set of prices being determined by anagreement between the second PBM and a pharmacy; ranking the at leastone price for the first drug in the first set of prices for the firstdrug and the at least one price for the first drug in the second set ofprices for the first drug in an order that is different from lowest tohighest; and displaying a price from said ranking in the user interface.2. The method of claim 1, wherein said ranking comprises, in response todetermining that the at least one price for the first drug in the firstset of prices is higher than or equal to the at least one price for thefirst drug in the second set of prices, ranking the at least one pricein the first set of prices higher than the at least one price in thesecond set of prices.
 3. The method of claim 2, wherein said ranking theat least one price in the first set of prices higher than the at leastone price in the second set of prices is performed in response todetermining that a difference between the at least one price for thefirst drug in the first set of prices and the at least one price for thefirst drug in the second set of prices does not exceed a thresholdvalue.
 4. The method of claim 2, wherein said ranking the at least oneprice in the first set of prices higher than the at least one price inthe second set of prices is based on a first acceptance rate associatedwith the at least one price in the first set of prices and a secondacceptance rate associated with the at least one price in the second setof prices.
 5. The method of claim 3, wherein a higher ranked price fromsaid ranking is displayed in the user interface.
 6. The method of claim3, further comprising determining a preferred order for ranking pricesfrom the first PBM and prices from the second PBM, the preferred orderindicating that prices from the first PBM are to be ranked higher thanprices from the second PBM.
 7. The method of claim 1, wherein: a firstpercentage indicates a portion of prices from the first PBM to bedisplayed in the user interface; a second percentage indicates a portionof prices from the second PBM to be displayed in the user interface; andsaid ranking comprises ranking the at least one price for the first drugin the first set of prices and the at least one price for the first drugin the second set of prices based at least in part on the firstpercentage and the second percentage.
 8. The method of claim 7, whereinthe second percentage is linked to a threshold value for ranking pricesfrom the first PBM over the second PBM such that adjusting the secondpercentage adjusts the threshold value and adjusting the threshold valueadjusts the second percentage.
 9. The method of claim 1, wherein: thefirst PBM administers claims relating to a first health insurance plan,and an agreement between the first PBM and a first pharmacy specifies aprice of the first drug for a member of the first health insurance planand a first price of the first drug for a customer that is not a memberof the first health insurance plan, the at least one price for the firstdrug in the first set of prices being the first price of the first drugfor a customer that is not a member of the first health insurance plan;and the second PBM administers claims relating to a second healthinsurance plan, and an agreement between the second PBM and a secondpharmacy specifies a price of the first drug for a member of the secondhealth insurance plan and a second price of the first drug for acustomer that is not a member of the second health insurance plan, theat least one price for the first drug in the second set of prices beingthe second price of the first drug for a customer that is not a memberof the second health insurance plan.
 10. The method of claim 9, furthercomprising: displaying in the user interface the first price of thefirst drug for a customer that is not a member of the first healthinsurance plan; and in response to selection of the first price receivedfrom the user interface, generating a discount coupon for a purchase ofthe first drug at the first price at the first pharmacy.
 11. A system ofdisplaying prices for drugs from a plurality of pharmacy benefitmanagers, the system comprising: computer hardware comprising one ormore computer processors; and a module executing on the one or morecomputer processors and configured to: provide a user interface using acomputer processor; receive information identifying a first drug fromthe user interface; obtain a first set of prices for the first drug thatis associated with a first pharmacy benefit manager (PBM), wherein apharmacy benefit manager processes a claim relating to a drug and has anagreement with one or more pharmacies relating to a price of one or moredrugs, the first set of prices comprising at least one price for thefirst drug and each price in the first set of prices being determined byan agreement between the first PBM and a pharmacy; obtain a second setof prices for the first drug that is associated with a second pharmacybenefit manager, the second set of prices comprising at least one pricefor the first drug and each price in the second set of prices beingdetermined by an agreement between the second PBM and a pharmacy; rankthe at least one price for the first drug in the first set of prices forthe first drug and the at least one price for the first drug in thesecond set of prices for the first drug in an order that is differentfrom lowest to highest; and display a price from said ranking in theuser interface.
 12. The system of claim 11, wherein the module performssaid ranking at least in part by, in response to determining that the atleast one price for the first drug in the first set of prices is higherthan or equal to the at least one price for the first drug in the secondset of prices, ranking the at least one price in the first set of priceshigher than the at least one price in the second set of prices.
 13. Thesystem of claim 12, wherein the module performs said ranking the atleast one price in the first set of prices for the first drug higherthan the at least one price in the second set of prices for the firstdrug at least in part in response to determining that a differencebetween the at least one price for the first drug in the first set ofprices and the at least one price for the first drug in the second setof prices does not exceed a threshold value.
 14. The system of claim 12,wherein the module performs said ranking the at least one price in thefirst set of prices higher than the at least one price in the second setof prices based at least in part on a first acceptance rate associatedwith the at least one price in the first set of prices and a secondacceptance rate associated with the at least one price in the second setof prices.
 15. The system of claim 13, wherein a higher ranked pricefrom said ranking is displayed in the user interface.
 16. The system ofclaim 13, wherein the module is further configured to determine apreferred order for ranking prices from the first PBM and prices fromthe second PBM, the preferred order indicating that prices from thefirst PBM are to be ranked higher than prices from the second PBM. 17.The system of claim 11, wherein: a first percentage indicates a portionof prices from the first PBM to be displayed in the user interface; asecond percentage indicates a portion of prices from the second PBM tobe displayed in the user interface; and the module performs said rankingat least in part by ranking the at least one price for the first drug inthe first set of prices and the at least one price for the first drug inthe second set of prices based at least in part on the first percentageand the second percentage.
 18. The system of claim 17, wherein thesecond percentage is linked to a threshold value for ranking prices fromthe first PBM over the second PBM such that adjusting the secondpercentage adjusts the threshold value and adjusting the threshold valueadjusts the second percentage.
 19. The system of claim 11, wherein: thefirst PBM administers claims relating to a first health insurance plan,and an agreement between the first PBM and a first pharmacy specifies aprice of the first drug for a member of the first health insurance planand a first price of the first drug for a customer that is not a memberof the first health insurance plan, the at least one price for the firstdrug in the first set of prices being the first price of the first drugfor a customer that is not a member of the first health insurance plan;and the second PBM administers claims relating to a second healthinsurance plan, and an agreement between the second PBM and a secondpharmacy specifies a price of the first drug for a member of the secondhealth insurance plan and a second price of the first drug for acustomer that is not a member of the second health insurance plan, theat least one price for the first drug in the second set of prices beingthe second price of the first drug for a customer that is not a memberof the second health insurance plan.
 20. The system of claim 19, whereinthe module is further configured to: display in the user interface thefirst price of the first drug for a customer that is not a member of thefirst health insurance plan; and in response to selection of the firstprice received from the user interface, generate a discount coupon for apurchase of the first drug at the first price at the first pharmacy.